Internet Publisher's Toolbox 2.0/Internet Publisher's Toolbox.iso/internet/email/pegasus/mercury/mguide.exe

David's Readme Compiler Executable | 1994-08-11 | 125.7 KB | 1,818 lines

xdYY=
6YY_^
l4YY_^
H9D0}
 ; A B D G H I K M O P Q R S s t u v
KvY_^]
 YYG;>
 A B D
ymY_^
<Ar    ,@
_^_^]
 H I K M P Q
 H I QA5)5
5 5-5/5U
YYF;v
;Dz~
:>;>;4;
;>;K;-;U
?DYPV
 H I K M P Q3A
DF_^]
YY9|,uK
;D@ui
;DDu2
H9D0~
9D<|    u
.Y;D2v
H9D0u
YY_^]
YY_^]
~-YY3
,Y)D:
C+Y;F
f)Y;D2wK
{^.97t
 G H I K M O P Q R S s t u wri8j8j
i8j8j
i8j8j+j
h^i(iU
t0Nt-
!r.RP
!r$RP
u/SQR
[[XP3
Turbo C++ - Copyright 1990 Borland Intl.
Null pointer assignment
Divide error
Abnormal program termination
$    ~ p
Courier
Do you want to overwrite
File exists
 Print Settings
 - Printing -
 Save as what file?
Failed saving to file!
 Failed!
 PgUp/Dn:
<F10>
 options
 PgUp/Dn
 Line %d of %d
 Search for
 Topics
 --- Searching ---
No matching entries found.
ind text   <F7>
find
gain  <F8>
rint entry
ave entry
dit entry
Printer port :
PostScript?  :
Press <Space> to change values
Created using
David's Readme Compiler v2.11
(c) 1990-93, David Harris.
e-mail: [e-mail]
LPT1:
LPT2:
LPT3:
%!PS-Adobe-2.0
%%Creator:DRC v2.0
%%EndComments
/leftmargin { 40 } bind def
/bot { 54 } bind def /top {
 } bind def
/cw { 40 } bind def
/xtab
 {currentpoint exch dup cvi
 leftmargin cvi sub cvi
 cw cvi mod sub
 cw add
 exch moveto
 } bind def
/ptsize { 12 } bind def /lead { 12 } bind def
/F { findfont exch scalefont setfont } bind def
/newline {
 currentpoint exch pop lead sub
 dup bot lt {
  pop showpage restore save
  top
  } if
 leftmargin exch moveto
 } bind def
%%Endprolog
%%BeginSetup
ptsize /| F
leftmargin top moveto
%%EndSetup
%.20s (Y/N)?
%-50.50s
newline
) show newline
newline
showpage restore
David's Readme Compiler, (c) 1992, David Harris.
Readme error: no attached data.
 About this Guide
MMMODE
 ; < = > ? @ A B C D T U V W X Y Z [ \ ]
 G O w u R S s t
EAEIIOOUUYIOU
(press any key to continue)
Insert paper in printer then press
a key (<ESC> cancels print)
 Printer error
The printer on LPT%d: is
confused
out of paper
off line
Correct then press a key
or hit <ESC> to cancel print
 Insert Paper
<ESC>
 key pressed:
Please confirm cancel/quit
Accept this data?
 Insufficient disk space
There is not enough space on the target
disk to receive the file(s): please replace
the disk with another formatted disk, then
press any key to retry, or <ESC> to cancel
 .,@:;
0123456789
         !!!!!
@@@@@@@@@@@@@@@
@@@@@@@
@@@@@@
@@@@
(null)
Data file generated by RCOM.
 Mercury Mail Transport System v1.13
Welcome to the Mercury Mail Transport System!
Main screen status line
Help on editing text
IMPORTANT information
General information
What's new in v1.13
What was new in v1.12
What was new in v1.11
What was new in v1.1
What is Mercury?
Upgrading Mercury
Installing Mercury
Mercury Features
Troubleshooting
Mercury Manuals
What is Mercury?
Contacting the author
Mercury and Charon
About this guide...
System Requirements
Queue or Spooler?
Spooler Interface
Queue Interface
Quick install
Using MINSTALL.BAT
Manual Installation
The Mercury Console
MERCURY.INI...
About MERCURY.INI
The [General] Section
The [Mercury] Section
The [Domains] Section
Domain literals
The [Rewrite] Section
The [MercuryC] Section
The [MercuryS] Section
Restricting connections
The [Groups] Section
The [Maiser] Section
Automatic replies
Pegasus Mail extended features
Template files
Distribution lists
Aliasing
POP3 server
About the POP3 server
Configuring MercuryP
User POP3 profiles
System POP3 profiles
Profiles for Pegasus Mail
Profiles for PMPOP
Profiles for Eudora
Terms
The List of Lists
Using lists
Other Maiser commands
Manual Availability
Mercury Manuals
Ordering manuals
Payment by credit card
Telegraphic Transfers
Orders from Europe
Terms and conditions
Mercury Manuals - Order Form
This electronic guide contains all the information you need to
install and use the Mercury system.
Please read the section marked "Important" on the main menu -
it contains information you MUST know before using this
version of Mercury.
If you wish to order a manual, you can edit and print the order
form from within this guide by pressing
<F10>
 and selecting
 while viewing the form.
Full search capabilities are available in this guide at any time
by pressing
, or selecting
Find text
 from the <F10> menu.
Please press
<Return>
 to continue...
         Mercury MTS, (c) 1990-1994, David Harris, all rights reserved
    Search, edit and print options available when reading by pressing <F10>
While editing this form, you can move from field to field using
<Tab>
 key (fields are delimited by
 and
Use the arrow and page keys to move around while editing. You can
delete text using the
<Del>
 and
<Bks>
 keys, and
<Ctrl-Y>
 will delete
a line.
You cannot alter the readme file from this screen, but you can save
the screen (with any changes you make) to a text file by pressing
<F10>
 and selecting
. You can print this form at any time from
the same menu.
Any changes you make will be lost when you close this screen.
Please press <Return> to continue...
Notes about this release:
 All sites using Mercury should add the following line to
  the Server's STARTUP.NCF file:
     SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE=2048
  Note that you can set a higher value if you wish, but you
  should not set it lower than 2048.
 Sites which use the SWITCH keyword in MERCURY.INI should
  change the setting from the old default (110) to either 1 or
  2 for Mercury 1.13. The old value results in almost no load
  on the server but very slow transmission of large messages.
  The new value causes some increase on load for large
  messages but results in nearly 5 times faster processing.
 Novell made changes to some versions of CLIB which can
  seriously affect Mercury's operation. Mercury 1.13 includes
  logic to work around these problems, but if you find mail
  messages appearing in your mail queue with odd job numbers,
  please read the file IMPORTAN.T! provided in this archive.
 A very rare, intermittent problem can occur which can send
  MercuryS into a never-ending loop receiving the same line over
  and over again. The DISCARD keyword in the [MercuryS] section
  of MERCURY.INI is designed to safeguard against this problem
  and should not be removed, although you can set it to a
  higher number than the default (30000) if you wish.
 Mercury 1.13 can only service the file server on which it runs.
 Mercury 1.13 does not support the SMTP EXPN command.
 Mercury 1.13 does not work with NetWare 4.0 in queue mode:
  in order to use Mercury 1.13 with NetWare 4.0, you must use
  the spool directory option. Mercury currently only operates
  under NetWare 4.0 servers in Bindery Emulation mode - support
  for NDS should be ready for the next major release.
Version 1.13 of Mercury is purely a maintenance release; it corrects
a problem in v1.12 which could cause the server to abend when very
long lines were received in a message. Maximum line lengths have also
been increased in this release.
Mercury 1.12 adds a small amount of new functionality and a number
of reliability and compliance fixes.
*  POP3 profiles. You can now customize the behaviour of MercuryP
   on a user-by-user basis using a POP3.PRO file in each user's
   SYS:MAIL directory. For more information, see the "POP3 server"
   topic under the "Mercury Features" section of this guide. The
   Mercury POP3 server has been heavily enhanced and should now
   be much more useful than previous versions.
*  ESMTP support. Mercury 1.11 claimed to support the 8BITMIME
   SMTP extension but in fact did not do so correctly. Because of
   this, Mercury 1.12 no longer advertises support for 8BITMIME,
   but DOES have support for the SMTP SIZE extension (RFC1427).
   You can control the maximum size which MercuryS will accept
   from compliant ESMTP clients by adding a SIZE: keyword to the
   [MercuryS] section of MERCURY.INI specifying the largest
   message size in bytes.
*  New MAISER commands: Mercury's mail server now recognizes two
   new commands:
   - FINGER <address>
     Returns mail-specific information about the specified address
     if it is local. Also returns the contents of the file PROFILE
     if it exists in the user's new mail directory. The FINGER
     command is intended to allow distribution of information such
     as PGP keys and contact information.
   - EXIT
     Terminates mail server command processing for a message.
*  You can now suppress the 25th-line broadcasts about the arrival
   of "confirmation of reading"-type messages by adding this line
   to the [Mercury] section of MERCURY.INI:
          Receipts : 0
*  Incoming mail logging: you can add a LOGFILE: parameter to the
   [MercuryS] section of MERCURY.INI which specifies a file into
   which MercuryS should record information about incoming mail
   transactions. Logging will not occur if this keyword is not
   specified.
*  Command-line host specification for MercuryC: MercuryC, the
   SMTP client module, has been multiply-loadable for quite some
   time, but can now have a host specified on the command line.
   This allows you to load more than one instance of MercuryC
   with each instance using a different smart mail host: doing
   this will ensure that mail processing continues normally if
   one smart host becomes unavailable, and also shares the load
   around. The syntax is
       LOAD MERCURYC -h <host_address>
   <host_address> must be in dotted numeric format (not a domain
   name). For example, if you want to load a copy of MercuryC
   which uses the machine at 192.156.225.2 as a relay, use:
       LOAD MERCURYC -h 192.156.225.2
*  PM_Notify option in [Mercury] in MERCURY.INI allows you to
   turn off the delivery of delivery failure notifications to
   the postmaster on the server. Use with care.
*  Ability to specify a static kill file for autoreplies. When
   generating an autoreply, Mercury now checks to see if there
   is a file called AREPLY.KFS in the user's mail directory. If
   there is, it is checked for the address before the autoreply
   is transmitted. AREPLY.KFS differs from the AREPLY.KFL file
   Mercury generates automatically in that Mercury never changes
   or deletes it. It is provided to allow a user to suppress
   certain autoreplies permanently. Addresses should be entered
   into AREPLY.KFS one per line, in their simplest form.
*  You can now force Mercury to change the ownership of mail
   to the recipient, by adding the line CHANGE_OWNER : 1 to
   the [Mercury] section of MERCURY.INI.
Mercury 1.11 is a consolidation release which fixes several
small problems in the 1.1 release - there is no appreciable new
functionality. The following changes have been made:
  MercuryS should receive messages anything up to twenty
   times faster than in 1.1 and problems with Mercury tying up
   100% of the server's resources should no longer occur.
  Mercury can now be told to use a file server directory for
   queuing mail instead of a NetWare Queue; in order to use this
   functionality you MUST be running Pegasus Mail/DOS v3.0,
   WinPMail v1.02 or later or Pegasus Mail/Mac v2.0.5 or later.
   The spool directory can be on any volume. Spooler support
   is enabled using the FILE_API keyword in MERCURY.INI. In order
   to run Mercury on NetWare 4.0x, you MUST use the spooler
   interface.
  When sending mail to a mailing list the To: address is now
   handled more tidily when the list is burst.
  Two new list definition keywords are available:
   - Restricted: if set to 'Y', only list members and moderators
     may mail to the list.
   - Errors_to: attempts to set an address to which errors and
     problems associated with list mail delivery should be sent.
  If a distribution list is NOT set to force replies to go
   to the list, then reply-to fields in incoming messages will
   now be preserved when the list is burst.
  Broadcast message notification of new mail can now be
   turned off globally using the BROADCAST keyword in the
   [Mercury] section of MERCURY.INI ("Broadcast: 0" will
   disable notification).
  Mercury now incorporates considerable loop detection logic
   - it should not be possible for it to get into an infinite
   processing loop with a message. Mercury achieves this by
   counting the number of RFC821 "received" headers in the
   message and discarding it once a certain number is reached.
   The default limit is 30 "received" headers, but this can be
   changed using a new MAXHOP keyword in the [Mercury] section
   of MERCURY.INI. A side effect of this addition is that
   Mercury itself now generates more "Received" headers than it
   used to which increases the size of messages slightly.
  MercuryC is now much more tolerant of connection failures
   and TCP/IP errors when despatching mail. When MercuryC gets
   a hard error it now requeues the job correctly and will
   continue to do so at five minute intervals indefinitely
   until the message is deleted by an operator or the user, or
   is successfully delivered. SMTP 500-series errors still
   result in immediate failure by Mercury.
  MercuryP has had the revised console added and now tracks
   the messages you have read via POP3; messages which are
   read during a session will not be offered to you in
   subsequent sessions even if they are not deleted. This
   behaviour is configurable using the new MARK_READ keyword
   in the [MercuryP] section of MERCURY.INI. If 1 (the default)
   then MercuryP WILL remember the messages you have read; if
   0, it will NOT remember and will present you with all new
   mail in your mailbox each time a connection is established.
  The problem in previous versions of Mercury which required
   the use of JOB statements in MERCURY.INI has been worked
   around and should no longer be a problem. JOB statements
   in MERCURY.INI are now ignored, although the same facility
   for remapping form numbers can still be achieved using
   FORM statements instead. Note that the format of the FORM
   statement is different from the JOB statement, although it
   should never be an issue in any case since the problem
   should no longer occur.
Mercury 1.1 includes the following new capabilities:
  Mail to NetWare groups. You must enable group mail on a
   group-by-group basis in Mercury.INI. See the section on
MERCURY.INI
 under
Installing Mercury
 for more information.
  Restrictions on connections. It is now possible to force
   MercuryS to restrict connections to explicit machines. For more
   information, see the section on
MERCURY.INI
 under
Installing
Mercury
  Much better timeout handling. You can control the timeout
   value for MercuryS, MercuryC and MercuryP using TIMEOUT entries
   in each one's section in Mercury.INI
  A new, improved console screen.
  Support for the SMTP VRFY command. This cost 5K of code but
   I've had sufficient requests that it seemed important.
  Limited ESMTP support. Mercury now recognizes the RFC1425 EHLO
   command and supports the 8BITMIME keyword defined in RFC1426.
   Support for the SIZE keyword (RFC1427) is coming shortly.
  Limited address rewriting capability. It's now possible to have
   Mercury rewrite the domain portion of most outgoing addresses in
   the message envelope (although not in the message itself). You
   might use this to force addresses in the form "user@host" to be
   rewritten as "[e-mail]".
  Considerably improved error handling and reporting.
  Support for the SMTP HELP command. The Help command displays
   the name of the MAISER account as part of its output.
  The Mercury NLMs should now load even if MERCURY.INI is not
   flagged SHAREABLE.
  Distribution list container files no longer need to exist
   before use - Mercury will now create them as necessary.
  Messages with From: fields which extend across multiple lines
   are now handled correctly.
  Mercury can now be told not to validate the From: field of
   incoming mail messages via the "gullible" keyword in the
   [Mercury] section of Mercury.INI.
  MercuryS and MercuryC can now announce themselves during
   the connection phase using a name different from "Myname",
   via the "helo" keyword in their respective INI sections.
  Messages which include quoted quotes in the Qtext part of an
   address are now handled correctly (for example an address like:
   "David \"Shotgun\" Harris" <[e-mail]>).
  Messages with attachments are now passed through correctly
   by Mercury when sent to distribution lists.
  Messages where the RCPT TO: field is given in source-routed
   form are now parsed correctly. Note that sending source-routed
   addresses in the RCPT TO: stage of the SMTP transaction is now
   considered illegal on the Internet - I have supported it under
   duress.
If you are already running a previous version of Mercury, you
can upgrade your installation either by running MINSTALL, or
by copying *.NLM from the distribution file into SYS:SYSTEM.
Note that there are many new features and capabilities in this
release of Mercury, many of which will only be enabled when
certain changes are made to MERCURY.INI. You should read this
guide carefully for information on the changes you might need
to make.
Here are a few common problems and solutions when using Mercury.
I can't send to or receive mail from Mercury
This and numerous variants of it make up over 95% of the problems
reported with Mercury. In general, this is a configuration problem,
either in NetWare TCP/IP or in your smart mailer. Things to check
include:
 Make sure you are actually loading TCPIP.NLM on the server
 Make sure your netmask is correct - it must agree with every
     other host on your network.
 Make sure you have the correct address specified in [MercuryC]
     for your smart relay host.
 If you have a name server, make sure it is advertising the
     correct IP address for your server.
 If you have used Charon in the past, make sure you don't have
     invalid MX entries lying around on the network.
I get "Loader could not find symbol 'inet_addr'" or similar loader
errors from NetWare when I try to load MercuryS or MercuryC
You have not loaded NetWare TCP/IP (TCPIP.NLM). Examine the NetWare
Red manual entitled "NetWare TCP/IP Transport Supervisor's Guide"
for more detailed information.
I can receive mail on Mercury but when I try to send I get a
message like "Error connecting to xx.xx.xx.xx; error 0 connecting
to server".
This situation usually indicates a TCP/IP routing error of some kind
on your network. Make sure that you have specified a
GATE=
 parameter
on the BIND line in your AUTOEXEC.NCF which ties IP to an Ethernet
card. If you are using a Domain Name Server at your site, make sure
that it knows about your server, and make sure that any routers which
might need to know about your server have been configured correctly.
Mercury is properly installed but mail isn't being processed
Run PCONSOLE and examine the queue. All jobs in the queue should have
either form number 101 or form number 110. If there are any jobs in
the queue with other job numbers, then you have a version of CLIB.NLM
in which Novell generously changed their APIs without telling anyone.
Read the file IMPORTAN.T!! in the Mercury distribution archive for
details on how to fix this problem. NOTE: the PCONSOLE queue list
only displays the first four digits of the form number - to see the
real form number, you must actually select a job and press <Enter> to
see its full details.
I can send mail out, but no-one can send mail to me
This usually means that your server's Internet name is not being
advertised on the Internet. You must have an entry in a DNS (Domain
Name Server) system somewhere which allows other sites to work out
your server's address from its name. Contact your IP network manager
or Internet Service Provider for details.
Mail goes out with the wrong "From" address even though I've changed
the MYNAME value in MERCURY.INI's [General] section.
You also need to change the Pegasus Mail configuration information to
reflect the new Internet name. Use the Pegasus Mail PCONFIG program
to do this.
MercuryS appears to timeout after the DATA statement from a host
which is trying to send it mail.
This usually means one of two things:
 The client is sending packets which are too large for your
     Server to accept. Try adding the command "set maximum physical
     receive packet size = 2048" in your STARTUP.NCF before you load
     your LAN driver.
 Your LAN driver or card cannot correctly handle IP packets. Some
     older versions of the WD drivers exhibit this problem. Upgrading
     to the most recent version of the driver (SMCPLUS for the WD
     family of cards) usually fixes it.
I see messages like the following on the Mercury consoles:
  "Socket read/write timeout or error"???
  "Connection error during handshake with xx.xx.xx.xx"???
  "TCP/IP error during processing"???
These errors all typically indicate a routing or traffic problem on
your IP network. Make sure that the "BIND IP" line of your server's
AUTOEXEC.NCF includes a "GATE=" parameter (we suggest you ignore the
Novell recommendation not to use GATE= when using RIP), and that all
IP routers on your network are aware of your server and how to find
I get errors like "503 Need recipient" from Mercury
This error (and any error like it starting with a digit) is actually
being issued by the mail host which Mercury uses to relay mail, not
by Mercury. It usually indicates an addressing problem in your
message, but you should refer it to the system manager on the mail
Every time I receive a mail message I get a "message loop" - the
message just bounces around between the smart host and Mercury
until eventually one of them discards it.
You almost certainly have an incomplete or inaccurate [Domains]
section in MERCURY.INI. You must list in your [Domains] section every
possible Internet name by which your file server could be addressed.
Mercury uses the [Domains] section to determine whether mail is local
or remote: if you omit a possible name for your server then Mercury
will not know that the mail is local and will refer it back to the
smart host, which in turn will send it back to Mercury... and so on.
Mercury is a mail transport system designed to work with Pegasus
Mail and compatible mail clients. It is intended as a "drop-in"
replacement for the Charon SMTP gateway developed by Brad Clements
of Clarkson University, but can do more and doesn't require a
dedicated PC.
Release 1.13 of Mercury provides a complete SMTP client and server
implementation which uses the NetWare TCP/IP stack provided with
NetWare 3.11. It also includes a comprehensive mail server which
can handle automatic mailing list management, file transmission,
user verification and more.
Like Pegasus Mail, Mercury is free software - you may install it
on as many servers as you wish without obligation or cost. Like
Pegasus Mail, manuals are optionally available for Mercury at
very reasonable prices, but there is absolutely no requirement
that you purchase them.
Although Mercury is free software, I support it rigorously and
welcome reports and comments about it. The best way to contact me
is via electronic mail:
   Internet:
[e-mail]
   CompuServe:
>internet:[e-mail]
I'm not currently addressable via MHS, but hope to be in the future.
If you wish, you can fax me at
([phone]
: although I will
try to answer your fax in good faith, the volume of paperwork I have
to manage means there may be quite some delay before you get a reply
or that you may get no reply at all. Electronic mail is the preferred
way of contacting me.
I can be phoned at
([phone]
, but please remember that New
Zealand is GMT+1200... I am generally pretty grumpy about being woken
at 4am by ANYONE! Because of the volume of information I have to deal
with, faxing me, or sending me paper mail will generally not elicit a
fast response - I apologise in advance for this, but there's only so
much one person can do. My postal address is:
        Pegasus Mail, c/- David Harris,
        P.O. Box 5451,
        Dunedin, New Zealand.
Brief summary of the differences between Charon and Mercury.
Mercury v1.13

Charon v4.0a

- Serves one server only             - Can serve up to eight servers
- Does not require a dedicated PC    - Requires a dedicated PC
- Supports only SMTP and POP3        - Supports other TCP/IP protocols
- Has a comprehensive mail server    - Has no mail server
- Distribution lists can be managed  - No distribution list management
  remotely, by mail
- Automatic subscription and
  unsubscription from lists          - No distribution list management
- Distribution lists can be          - No distribution list management
  moderated and restricted
- User lookup and validation both    - SMTP VRFY command supported
  by e-mail and SMTP VRFY command.
- Disk-based aliasing for almost     - Memory-based aliases
  unlimited numbers of aliases
- Automatic reply (like the Unix     - No automatic reply function
  vacation command) with memory
- Error messages and notifications   - Messages cannot be customized.
  can be tailored to the site.
- BITNET address rewriting           - No address rewriting
- Mailing lists can be added and     - Mailing lists cannot be added
  updated while the system runs        or updated while the system runs
- POP3 server supplied               - No POP3 server supplied
- Broadcast notification messages    - Broadcast messages only show
  include subject and urgency          the sender of the message
- Extended SMTP support (RFC1425)    - No ESMTP support
This user guide was created entirely using another of my programs,
called
David's Readme Compiler
 (DRC). DRC allows you to take
a simple text file and "compile" it into a single .EXE file which
you can include with your program. This reduces the number of files
you need to supply. DRC allows you to create hierarchical sub-topics
nested arbitrarily deeply and to control text attributes and colour.
It also has a mode which leaves the screen undisturbed, so you can
run it as a help system from inside other programs.
DRC is
totally free
, no catches, gotchas or gimmes. You can get it
via anonymous FTP from
risc.ua.edu
 in /pub/network/pegasus/drc21.zip.
Drc21.zip can also be found at splicer2.cba.hawaii.edu in the directory
/files/pegasus and on CompuServe.
Mercury requires NetWare 3.11 with the NetWare TCP/IP transport
module loaded and correctly installed. It is not fussy about the
particular details of the TCP/IP settings, provided the transport is
running. In normal use Mercury will take approximately 70KB of server
RAM and 2 BSD sockets, and should not significantly slow the per-
formance of the server. Mercury runs under NetWare 4.0 in Bindery
Emulation mode only, and only using the spool directory interface.
(I'm still working towards native NetWare 4.0 NDS support).
Mercury can interface with Pegasus Mail (and compatible mailers)
in one of two ways:
Via a NetWare queue:
 This has the advantage that familiar
  NetWare tools such as PCONSOLE can be used to manage the mail
  queue; as well, it is very difficult to forge mail when using
  the queue interface.
Via a spool directory
 (a directory on the file server in
  which all users with access to SMTP services have [C] rights).
  The spool directory has the advantage that it places little
  extra load on the server, can be located on any volume, and
  has no limits on the maximum number of simultaneous jobs in
  the queue. It is also an easier interface to write to for
  compatible mailers and gateways, requiring no NetWare API
  calls or awareness.
The choice of which interface you use is up to you, but there
are some specific caveats:
* If you are installing Mercury on a NetWare 4.0 server, then
  you can ONLY use the spool directory interface.
* To use the spool directory interface, you must be using Pegasus
  Mail/DOS v3.0 or later, WinPMail v1.02 or later, or Pegasus Mail
  for the Mac v2.0.5 or later. Earlier versions cannot access the
  spool directory interface.
To install Mercury to use a Spool Directory interface on your
server, follow these steps:
1: Create a directory somewhere on your server into which
   mail files are to be spooled.
2: Create a NetWare group which contains those people who are
   to have access to SMTP mail services (you can use the group
   EVERYONE if all users are to have access) and grant the
   group [C] rights to the directory.
3: Edit MERCURY.INI and add the following line in the [GENERAL]
   section of the file:
        FILE_API : 1
4: Alter the MAILQUEUE and SMTPQUEUE entries in the [GENERAL]
   section of MERCURY.INI so that they contain the path to the
   directory you created in step 1, in NETWARE format (for
   example,
SYS:MERCURY/SMTPQUEUE
5: DO NOT RUN ADDQ! It is NOT necessary if you are using the
   spooler interface, and will not run under NetWare 4.0 in
   any case.
Mercury services mail from a NetWare Queue, which must exist
the first time you load Mercury - it will not create it.
If you are currently using the Charon Gateway and Pegasus Mail,
then Mercury can use your existing Charon queue - PROVIDED that
Charon is not using it as well. If you intend to keep Charon
running for a time while testing Mercury, then you must run
Mercury on a separate queue.
To create the mail queue for Mercury, simply use the NetWare
PCONSOLE command as you would normally to create a print queue.
Once you have created the queue, run ADDQ.EXE from the Mercury
archive - the syntax is "ADDQ <queue_name>". Addq simply makes
user SUPERVISOR a valid server for the queue, which allows
Mercury to service the queue from connection 0.
The sample MERCURY.INI supplied with the distribution archive
turns on almost every Mercury feature, and is suitable for most
sites with only a couple of changes. If you want to get Mercury
up and running as quickly as possible, use the MINSTALL batch
file to install the system, then alter the following entries in
SYS:SYSTEM/MERCURY.INI
  In the [General] Section:
  Myname     - Set this to the canonical name of your server.
  Timezone   - Set this to your time zone
  Mailqueue, - Set this to the name of the queue you create
  SMTPqueue    for Pegasus Mail. If you are replacing a Charon
               server you will probably enter "MAILQUEUE" for
               both entries. If you are using Mercury's spooler
               interface, set the value to your spool path.
  In the [Mercury] Section
  Postmaster - Set this to the NetWare UIC of the user who
               is to be postmaster on this server.
  In the [MercuryC] Section
  Host       - Set this to the IP address of the machine
               which will relay outgoing mail for you.
               Note - it MUST be an IP address, not a name.
  In the [Domains] Section
  Place an entry in the form <servername> : <internetname>,
  where <servername> is the NetWare name of this file server,
  while <internetname> is the Internet domain name which
  other sites will use as an address for the server. You should
  also add an entry which says <servername> : <servername> (ie,
  both sides of the ':' are the same) to allow local delivery.
That should be all it takes! If you have entered the correct
values, Mercury should load and run without further problems.
The Mercury archive includes a simple batch file called MINSTALL
which will do the file-shuffling part of the Mercury installation
for you. To run MINSTALL, make sure you are in the directory in
which you unpacked MERC100.EXE, then type MINSTALL.
*** NOTE: MINSTALL will attempt to map drive K: to SYS:SYSTEM;
*** edit the batch file if you want it to use another drive letter.
MINSTALL moves the NLMs into SYS:SYSTEM, creates SYS:SYSTEM\MERCURY
and copies the Mercury support files there, and flags MERCURY.INI
as shareable.
Once MINSTALL has completed, you should modify MERCURY.INI as
described in this guide.
Mercury can be installed from DOS by running the MINSTALL batch file
from the directory in which you unpacked MERC100.ZIP, or by hand
using the following instructions:
 1:  Copy the 3 Mercury NLMs (MERCURY, MERCURYC and MERCURYS) and
     the sample MERCURY.INI file into SYS:SYSTEM.
 1a: If you intend to use Mercury's POP3 support, copy MERCURYP.NLM
     into SYS:SYSTEM as well.
 2:  Create SYS:SYSTEM/MERCURY, and copy the remaining files from
     the Mercury archive into this directory.
 3:  If you are using Mercury's default NetWare Queue Interface, run
     the ADDQ.EXE program supplied in the archive. This program
     simply makes the user SUPERVISOR a valid server for the queue
     you specify. This is necessary for Mercury to be able to run.
     If you are using Mercury's Spooler interface you should
     run ADDQ.
 4:  Make any changes necessary to MERCURY.INI (see next topic).
 5:  From the NetWare console, issue the commands:
        LOAD MERCURY
        LOAD MERCURYS
        LOAD MERCURYC
     (You will probably also want to add these commands to the end of
     your AUTOEXEC.NCF file).
 6:  Flag SYS:SYSTEM/MERCURY.INI Shareable (this is important).
Each Mercury module opens a console screen where it logs progress
messages and general operation information. You can cycle between
the various console screens on the server by pressing <Alt+Esc>
if you are at the console, or the Grey <+> key if you are using
RCONSOLE.
Each console screen has a header section which identifies the
module and provides some ongoing statistics. The statistics
provided in each header are as follows:
Mercury.NLM
Name:
    The name of the host (MYNAME in Mercury.INI)
       The name of the mail queue Mercury is serving
Domains:
 The number of entries in the [Domains] section,
            which equates to the number of possible addresses
            Mercury is currently servicing.
       The number of mail jobs Mercury has processed
            since it was loaded.
       The number of errors which have occurred since
            Mercury was loaded.
MercuryC.NLM
Name:
    The name of the host (MYNAME in Mercury.INI)
       The name of the mail queue MercuryC is serving
Host:
    The IP address of the machine which MercuryC is
            asking to relay mail.
       The number of mail jobs MercuryC has processed
            since it was loaded.
       The number of errors which have occurred since
            Mercury was loaded.
MercuryS.NLM
Name:
    The name of the host (MYNAME in Mercury.INI)
       The name of the mail queue MercuryS is serving
       The number of mail jobs MercuryS has processed
            since it was loaded.
       The number of RFC1425 ESMTP connections which
            MercuryS has accepted since it was loaded.
       The number of times MercuryS has refused to
            accept a connection since it was loaded.
MERCURY.INI is a text file located in SYS:SYSTEM which is read by
all the Mercury NLMs when they load. It MUST be flagged Shareable
or else you may get unsynchronized load errors when you load the
NLMs from AUTOEXEC.CNF.
MERCURY.INI can be edited with any text editor, and is not held
open while Mercury is running - it is only interrogated at the
time the system loads.
The [General] section contains settings common to all modules;
Myname:
   Domain name for your server; Mercury can derive the server's IP
   number from the OS, but it cannot derive the name. Enter here the
   name which your Name Server returns as the IN A entry for this file
   server. Unlike Charon, Mercury ONLY requires MX entries if you wish
   to provide aliased names for your servers.
File_API:
   If this keyword is present and has a non-zero parameter, then
   Mercury will use a spool directory interface instead of a NetWare
   queue for mail management. If omitted (the default) Mercury will
   expect to use a NetWare queue.
Mailqueue:
   The name of the queue into which outgoing mail should be placed. If
   you have previously installed the Charon gateway, you can use the
   Queue you created for Charon. This is the queue into which Pegasus
   Mail and compatible clients will place mail for processing. If you
   are using Mercury's Spooler interface, then give the path to your
   spool directory in this field.
Timezone:
   The timezone string the Mercury modules should add to Date: fields
   in messages. This string must not be longer than 10 characters.
       Example:
             "timezone: GMT+11"
       yields the date
             "Mon, 29 Mar 93 23:10:33 GMT+11"
SMTPQueue:
   The name of the queue in which the SMTP client should look for jobs
   to send off-server. This queue can be the same as the mailqueue, and
   usually should be except on exceptionally busy servers.  If you
   are using Mercury's Spooler interface, then give the path to your
   spool directory in this field.
The [Mercury] section contains settings for MERCURY.NLM, the central
delivery engine. MERCURY.NLM is responsible for examining mail in the
mailqueue and deciding whether it is to be delivered locally (which
it will then do), or else passed to the SMTP client to be sent
off-server. It also contains a simple Mail Server, and the aliasing
and synonym mechanisms.
Failfile, Confirmfile
   Template files, the first for Delivery failure notifications, the
   second for Delivery confirmations. Sample versions of these files
   are provided and can be used without changes. The template file
   format is described later.
Aliasfile
   Points to a file of aliases. Aliases are equations for full
   addresses, and are created and maintained with MALIAS.EXE. The
   alias file may be updated while Mercury is running - for an
   example of the format of the source file used for aliasing, see
   the file ALIAS.SRC.
Syn_file
   Points to a synonym file. Synonyms allow a user to have a From:
   address in messages which is different from their NetWare UIC
   (which is the normal mail address when using Mercury and Pegasus
   Mail). Synonyms might allow user "DAVID", for instance, to use the
   address "D.Harris". Synonyms are created and maintained using the
   Pegasus Mail PMGRANT program, and the synonym database is created
   using CH_SYN.EXE. The difference between Synonyms and Aliases is
   that Synonyms are bi-directional - that is, Pegasus Mail uses it
   in outgoing messages and Mercury recognizes it in incoming
   messages. Aliases usually only work in one direction. A user may
   have only ONE synonym, and need not have any if you choose not to
   use them.
Listfile
   The name of the "List of lists" - a file defining distribution
   lists managed by Mercury. For more information, see the section
   below entitled "Distribution lists".
Logfile
   The name of a file where Mercury should record mail traffic. The
   sender, addressee, time, date and size of the messages are
   stored. If you do not specify a logfile field, no logging will be
   done.
Logwidth
   Optional integer specifying the maximum width of address fields
   in the log file. The default value is 30 characters for each
   field.
BitnetHost
   Mercury can perform limited, simple-minded address rewriting of
   BITNET addresses, which many smart mailers cannot mail directly.
   If you specify a value here (in the sample file, for instance, it
   is "cunyvm.cuny.edu"), then addresses in the form
       "[e-mail]"
   will be sent as
       "[e-mail]".
   How often (in seconds) Mercury should check for new jobs in the
   mailqueue. Once every ten seconds is a good setting.
Broadcast
   An integer value (1 or 0, default 1). By default, Mercury sends
   a NetWare broadcast message to users if they are logged in when
   new mail arrives. Individual users can disable this feature using
   CASTOFF or Pegasus Mail's extended preferences options, but you can
   also disable it for the entire server by including this optional
   keyword and setting it to 0.
Receipts
   An integer value (1 or 0, default 1). If 0, then Mercury will not
   send NetWare broadcast messages about the arrival of messages
   which simply advise "confirmation of reading". The mail itself
   will be delivered, but no broadcast message will occur. By
   default, Mercury will send broadcast messages for every new mail
   message which arrives.
Gullible
   An integer value (1 or 0) which determines whether or not Mercury
   should check that a message has a valid From: address before
   delivering it. If Mercury is to operate in Gullible mode (1), then
   it will accept any message and attempt to deliver it.
Scratch
   Where Mercury can create temporary files. Usually the location in
   which you store your template files is a good choice. You may
   want to consider using the NetWare FLAGDIR command to set this
   directory's auto-purge flag.
Returnlines
   How many lines Mercury should write from the original message
   when it encounters the ~G substitution in template files.
Switch
   Is an optional integer telling Mercury how many times to yield
   the processor per operation during intensive I/O. The default is
   0, which may be too low for very busy servers. Setting SWITCH: 1
   will usually result in a marked improvement in server performance.
   Mercury should almost never need this entry, although MERCURYC
   may need it on occasion.
Postmaster
   NetWare UIC of the user on this server who is to receive messages
   delivered to Postmaster. This cannot be an alias or synonym.
** Note: PostMaster is a MANDATORY setting. Mercury will NOT run
** correctly if it is omitted. DO NOT AUTOFORWARD THIS ACCOUNT!
PM_Notify
   An integer value (1 or 0, default 1) which determines whether or
   not Mercury should send copies of all delivery failures to the
   postmaster defined on the server. If set to 0, then Mercury will
   only return the error to the sender, not to the postmaster. Use
   this option with care - Mercury sends failure information to the
   postmaster for a reason, since it can indicate possible config-
   uration errors on your system. If your postmaster is not prepared
   to field these messages, you should possibly consider appointing
   a new postmaster.
Change_owner
   An integer value (1 or 0, default 0) which controls whether or
   not Mercury should change the ownership of mail it delivers to
   the recipient. If set to 1, then mail will count against the
   recipient's disk quota on the SYS: volume. This option should be
   used with care since in pathological cases it can result in loss
   of mail.
The [Domains] section is used to tell Mercury about the possible
names by which your server might be known to other machines on your
TCP/IP network. You must list in this section every domain name (the
portion of an address following the '@' symbol) which might be used
to mail to your server, since Mercury determines whether or not an
address is local based on this information. Omitting server domain
names from this section will almost certainly result in mail loops.
Entries in the [Domains] section bind a particular domain address to
a particular NetWare server. You must supply at least one domain for
Mercury to function. The format of the Domains section is:
   NetWare_server_name   :  domain_name
As an example, if you have a NetWare server for which the NetWare name
is THALIA, and the Internet name is URANIA.PMAIL.GEN.NZ, then your
[Domains] entry will look like this:
   THALIA : urania.pmail.gen.nz
To allow local delivery, you should always add an entry which equates
your server name to your server name - like this:
   THALIA : THALIA
Mercury will NOT add this entry automatically in case you have
unusual duplicate naming schemes at your site.
You can repeat a server name with several different domain addresses,
but you may not repeat a domain name for several different servers;
   THALIA : urania.pmail.gen.nz
   THALIA : pmail.gen.nz
is a legal [Domains] list, but -
   THALIA : urania.pmail.gen.nz
   URANIA : urania.pmail.gen.nz
is not.
There is a seldom-used address format called a domain-literal
form, which consists of the IP address of the target machine
in square brackets (example
user@[192.156.225.2]
Although the domain-literal form is discouraged in standards
documents, some older mail systems use it from time to time.
Mercury will accept domain literal references, but will not
do so automatically - to allow domain literal forms, you must
add an equation for them to your domains section, like any
other domain reference. The form of the entry should be as
follows:
    SERVER : [www.xxx.yyy.zzz]
Example - your server's IP address is 192.156.225.16: you
would enter this in your [Domains] section -
    THALIA : [192.156.225.16]
Mercury can perform limited rewriting on addresses in the envelope
portion of outgoing mail; typically this will be used to ensure
that addresses in the message envelope go out as FQDN forms,
although it can also be used to perform a certain amount of crude
domain rewriting as well.
Entries in the [Rewrite] section consist of a domain portion to
match and the substitution to perform. For example, the [Rewrite]
entry:
      myserver : myserver.pmail.gen.nz
tells Mercury to rewrite any addresses where the domain portion
consists of "myserver" to a fully-qualified form. The match (left-
hand side) is not case-sensitive, but otherwise must match exactly.
You can define a special "default rewrite" by specifying "*" as the
match: this rewrite ADDS the substitution to any domain which does
not contain a period in its domain portion. So the rewrite entry:
     *   :   pmail.gen.nz
Would cause the address "david@parnassus" to be rewritten as
"[e-mail]".
Restrictions: because the address rewriting facility is really just
a string match and replace, there are certain restrictions on its
use and capabilities:
  Source-routed address forms cannot be rewritten.
  Bang-style (uucp) addresses (anything containing a '!')
   will not be rewritten.
  The rewrite occurs ONLY in the ENVELOPE to the message,
   not in the actual message headers themselves.
The MercuryC section contains settings for the Mercury SMTP client -
the module which transfers mail from your server to the outside
world using the SMTP protocol.
Scratch, failfile, returnlines, poll
   Are all the same as in the [Mercury] entry, and may have the same
   values, or may differ. The Poll parameter in particular will
   usually be longer than the Poll time in the [Mercury] section.
   Allows you to define a name different from "Myname" which
   MercuryC should use when connecting to the smart mailer. Most
   sites will not need to use this parameter.
   The Internet address of the host which MercuryC will ask to relay
   mail. Like the Charon SMTP gateway, MercuryC does not actually
   attempt to deliver mail itself - it passes it to a "smart" mailer
   which will do so. Typically the smart mailer is a UNIX machine.
   The Host address must be specified in dotted numeric format - for
   example "192.156.225.2", because NetWare's TCP/IP does not
   implement a proper name resolver.
Switch
   Is an optional integer telling MercuryC how many times to yield
   the processor per operation during intensive I/O. The default is
   0, which may be too low for very busy servers. Setting SWITCH: 1
   will usually result in a marked improvement in server performance
   on busy servers.
Timeout
   Specifies the number of seconds MercuryC should wait without
   seeing data on the socket before timing out. The default value
   is 300 seconds.
MercuryS is the SMTP listener, which handles incoming SMTP mail.
Debug
   If non-zero, then MercuryS will display more information about
   incoming connections on its screen.
   Allows you to define a name different from "Myname" which
   MercuryS should use when accepting connections from other
   systems. Most sites will not need to use this parameter.
Switch
   Is an optional integer telling MercuryS how many times to yield
   the processor per operation during intensive I/O. The default is
   0, which may be too low for very busy servers. Setting SWITCH: 1
   will usually result in a marked improvement in server performance.
Refuse
   The parameter is an Internet address in dotted format. This
   keyword defines an address or range of addresses from which
   MercuryS should NOT accept connections. (See next section)
Allow
   The opposite of Refuse - specifies an address or range of
   addresses from which MercuryS SHOULD accept connections.
Timeout
   Specifies the number of seconds MercuryS should wait without
   seeing data on the socket before timing out. The default value
   is 300 seconds.
Discard
   Specifies the maximum number of lines a message may have before
   MercuryS will refuse to accept it. This keyword is provided to
   work around a rare intermittent problem in MercuryS.NLM and
   hence should not be removed, although you may set its value to
   a larger or smaller number than the default (30000). When
   MercuryS detects that the line limit has been breached it will
   perform an emergency close on the connection and discard all
   data received up to that point.
   Specifies the largest message MercuryS should agree to accept
   from mailers compliant with RFC1427 (the SMTP SIZE extension).
   The value is specified in bytes, with 0 (the default) meaning
   no limit.
Logfile
   Indicates that MercuryS should record details of all incoming
   transactions in the file specified. This file MUST NOT be the
   same as either the Mercury log file or the Maiser log file. If
   this keyword is absent, no incoming logging will be performed.
   Be aware that the logfile generated by this feature can become
   very large very quickly, and should be purged regularly.
MercuryS does no validation on incoming addresses - it simply places
them as jobs in the Mailqueue, and allows MERCURY.NLM to decide what
to do with them. MercuryS DOES support the SMTP VRFY command though.
It is possible to tell MercuryS to refuse or accept connections only
from specific addresses or ranges of addresses. By default, MercuryS
will accept connections from anywhere.
To create an access control list for MercuryS, use REFUSE and ALLOW
keywords in the MercuryS section of Mercury.INI. You can use REFUSE
and ALLOW as often as you wish in the section. A '0' anywhere in the
address you provide to either keyword is taken as a wildcard - so
the address
139.80.0.0
 is taken to mean "Any address in the class B
domain 139.80.x.x".
 that the order in which REFUSE and ALLOW entries appear in the
[MercuryS] section is CRITICAL. MercuryS evaluates them in order when
deciding when assessing a connection, and stops evaluating on the
first match.
Example:
 Permit only 139.80.128.2 in the 139.80.x.x domain to
connect to Mercury
   [MercuryS]
   Allow  : 139.80.128.2
   Refuse : 139.80.0.0
Example:
 Allow only connections from 139.80.x.64
   [MercuryS]
   Allow  : 139.80.0.64
   Refuse : 0.0.0.0
Note that there is an implicit rule "Allow 0.0.0.0" at the end of the
list, so if an address drops through the bottom of the restriction
list (that is, matches no entry), Mercury will allow it to connect.
Mercury can deliver mail to NetWare user groups on your server.
Because this is a potential security risk (imagine someone sending
malicious mail to group EVERYONE), you have to enable mail to groups
on a group by group basis.
To allow mail to a group, create a [Groups] section in your .INI
file, using the following syntax:
     address  :  group_name
Address
 is the address which Mercury will associate with the group.
   It can be the same as the NetWare groupname if you wish.
Group_name
 is the actual NetWare name of the group.
Example:
  to enable group mailing to group MAILUSERS using the
   address "everybody", enter:
      [Groups]
      everybody : MAILUSERS
You may have as many entries in the GROUPS section as you wish.
As mentioned above, MERCURY.NLM incorporates a simple mail server,
which can respond autonomously to a limited number of commands in
response to a mail message. The [Maiser] section controls the Mail
Server. If it is absent, the Mail Server functions will be disabled.
Maiser
   The name of the address which MERCURY.NLM should interpret as
   being the mail server. This should NOT be a valid account on your
   server - it is a fictitious address to which mail is never
   directly delivered: setting MAISER to point to a real account
   effectively prevents the real account from ever receiving mail.
   The value in the sample INI file is MAISER, and I STRONGLY urge
   you to use this name unless you have extremely solid reasons for
   altering it.
Helpfile
   The name of a file which the mailserver should send back in reply
   to the message body "HELP". A sample file is provided which you
   may use if you wish. This file is NOT a template file.
Lookupfile
   The name of a template file which the mailserver should use to
   form replies in response to the LOOKUP command. This IS a template
   file, and should contain the substitution "~R" at the point where
   the mail server should enumerate the successful matches. If you do
   not supply a value for Lookupfile, the Maiser's lookup function
   will be disabled, and anyone requesting a lookup will receive a
   failure notification to this effect.
Logfile
   The name of a file where MAISER should record traffic. The sender,
   time, date and commands issued are recorded. If you do not
   specify a logfile field, no MAISER logging will be done.
*** DO NOT set the Maiser log file to the same file as the
*** Mercury log file.
Send_dir
   The name of a directory containing files which users may ask the
   maiser to send using the SEND command. Files in this directory
   must be ASCII text files, so if you want to make binaries
   available you will have to uuencode or binhex them yourself. If
   you choose to make files available by mail, you should place a
   file called INDEX.TXT in this directory: this is the file Maiser
   will send in response to the INDEX command, and usually contains
   descriptions of the available files (although it can contain
   anything). The send command is quite secure - it will ONLY accept
   filenames in the specified directory. If you wish to disable the
   send command, then make sure that there is no Send_dir field in
   your MAISER section.
Mercury can manage auto replies for Internet mail, much the same way
the UNIX "Vacation" program does. To enable auto-reply for a user,
create a file in his/her SYS:MAIL subdirectory called AREPLY.PM,
containing the message to be returned to the sender. Mercury will
look for this when delivering mail to the account, and will return
its contents immediately the message is delivered locally.
To avoid the possibility of mail storms (which can happen when two
accounts start auto-replying to each other, or when an autoreply is
sent to a list server), Mercury remembers every address from which a
message has been successfully delivered for the account in the last
48 hours; if more than one message comes in from the same address in
any 48 hour period, Mercury will generate only one auto-reply. The
auto-reply memory is stored in a file called AREPLY.KFL in the
user's SYS:MAIL directory.
You can also specify a static kill file for autoreplies on a user by
user basis. When generating an autoreply, Mercury checks to see if
there is a file called AREPLY.KFS in the user's mail directory. If
there is, it is checked for the address before the autoreply is
transmitted. AREPLY.KFS differs from the AREPLY.KFL file Mercury
generates automatically in that Mercury never changes or deletes it.
It is provided to allow a user to suppress certain autoreplies
permanently. Addresses should be entered into AREPLY.KFS one per
line, in their simplest form.
Mercury recognizes and honours all Pegasus Mail extended features
applicable to it. To enable autoforwarding by Mercury for an
account, an address should be placed in the "Internet AF" field in
Pegasus Mail's extended features (just like Charon).
Mercury recognizes and honours Charon Synonyms.
Mercury is capable of generating a certain number of messages
autonomously: good examples are Delivery Confirmations and Delivery
Failure messages. Rather than use hard-wired messages (like
sendmail's awful delivery confirmations), Mercury allows you to
create Template Files - pre-written models which it will use to
write the messages, filling in the blanks as necessary.
Template files are complete messages, including headers, and must be
formatted as such. Template headers must conform to RFC-822, but the
message body of a template can contain anything you wish. You can
tell Mercury to substitute certain values in a template by placing a
tilde followed by a code at the point in the message where you want
the substitution to occur. The following Template substitutions are
supported by Mercury:
~D  -  Replaced with the current time and date in full RFC-822 date
       format, without the "Date:" keyword.
~T  -  Replaced by the "to" address of the message, without the
       "To:" keyword.
~S  -  Replaced with the "Subject:" field for the message, without
       "Subject" keyword.
~R  -  Indicates the point in the template at which Mercury should
       print its result file. For delivery failure, the result file
       contains the errors; for user lookups, it contains the result
       of the search; for delivery confirmation, it contains the
       addresses to which the message was successfully delivered. Its
       value for other templates is undefined.
~M  -  Indicates that Mercury should dump the entire original message
       into the outgoing message.
~G  -  Indicates that Mercury should dump lines from the original
       message,  up to the value defined in "returnlines" in
       MERCURY.INI, into the outgoing message.
~N  -  Replaced with the domain name of the server.
~~  -  Replaced with a single tilde.
Other substitutions may be added in future versions. The Mercury
distribution includes the following sample template files which you
can use unmodified at your site if you wish: FAILURE.MER (Delivery
failure notification), CONFIRM.MER (Delivery success notification)
and MAISER.LKP (template for a successful MAISER lookup operation).
Mercury supports disk-based aliasing for addresses. Aliases may
be created, added or updated while Mercury is running.
To use aliases, create a text file containing the alias equations
then compile it using MALIAS.EXE. The resulting file should be
placed in the location specified in MERCURY.INI.
For an example of the format MALIAS expects, examine the file
ALIAS.SRC provided in the distribution archive.
Mercury includes a mail forwarding server which conforms to
RFC-1225 (POP3, or Post Office Protocol v3). The POP3 NLM
is called MERCURYP.NLM, and can be loaded with or without
the other Mercury components.
MercuryP is a full implementation of all commands in RFC1225
(although RPOP is treated no differently from PASS), and any
legal POP3 client should be able to access it on port 110.
MercuryP can be run on its own, or in conjunction with
the other Mercury system modules. It has its own section
in MERCURY.INI, called [MercuryP], which can contain the
following keywords:
Scratch : <path>
   Points to a directory in which MercuryP can create
   temporary files. If absent, the default is SYS:SYSTEM.
Switch : <integer value>
   Is an optional integer telling MercuryS how many times
   to yield the processor per operation during intensive
   I/O. The default is 0, which may be too low for very
   busy servers. Setting SWITCH: 1 will usually result in
   a marked improvement in server performance at the cost
   of slightly slower mail transactions.
Mark_read : <1 or 0>
   Controls whether or not MercuryP should mark messages
   which are downloaded but not deleted as read when the
   connection is closed. Combining this option with the
   option many POP clients of not deleting downloaded mail
   provides a way of getting only new mail from the server
   while leaving it there for later use when attached.
   Note: the Mark_Read switch duplicates the capabilities
   of the user profile, POP3.PRO, described in the next
   section, on a global basis.
Each user on the server can have a file called POP3.PRO in his
new mail directory which contains settings MercuryP will use
when a POP3 connection is established. POP3.PRO is a simple
text file, editable with any text editor (such as the DOS EDIT
command). The following keywords can be used in it:
Mark read : <Y or N>
   If Y, then MercuryP will mark as having been read any
   messages downloaded during a session but not deleted.
Show read : <Y or N>
   If Y, then MercuryP will show all messages in the user's
   new mailbox when asked for a list by a POP3 client. If N,
   then only mail which has NOT been marked as read will be
   presented.
Show status : <Y or N>
   If Y, then MercuryP will generate artificial "Status:"
   headers such as might be found in a Unix mailbox. Usually
   these headers are not present since neither Pegasus Mail
   nor Mercury relies on them for status information about
   the message, but other POP3 mailers (such as Eudora) rely
   on these headers to provide functionality.
No delete : <Y or N>
   If Y, then MercuryP will not delete messages even when
   instructed to do so by the POP3 client. This is useful if
   you are using a POP3 client which cannot be configured to
   leave messages on the server, and you want to do so.
Delete is final : <Y or N>
   If Y, then any mail deleted using the POP3 DELE command
   will be deleted if the connection to the server is lost.
   The default condition is for mail deleted using DELE to
   be recovered if the connection terminates abnormally. If
   you routinely access your mail across a slow or unreliable
   TCP/IP link (e.g, SLIP) you may prefer to set this to Y.
As well as user POP3 profiles (see the previous section) you
can define a system-wide POP3 profile by creating a file using
the same syntax, called SYS:SYSTEM/POP3.PRO. The system-wide
profile is read first, and then the user profile (if any) is
applied. Settings in the files are cumulative, so a setting
applied in the system profile will remain after a user profile
is read unless the user profile explicitly alters it.
Pegasus Mail for Windows 1.1 has built-in POP3 support. If you
want to leave your mail on the server for later browsing when
connected to the LAN, but only want to be presented with new
(unread) mail via POP3, then use the following profile settings:
      Mark read : Y
      Show read : N
      Show status : N
      No delete : N
      Delete is final : <your preference>
PMPOP is the POP3 gateway for the DOS version of Pegasus Mail:
If you want to leave your mail on the server for later browsing
when connected to the LAN, but only want to be presented with new
(unread) mail via POP3, then use the following profile settings:
      Mark read : Y
      Show read : N
      Show status : N
      No delete : N
      Delete is final : <your preference>
The recommended settings when using Mercury with Steve Dorner's
excellent Eudora POP3 mailer in its "Leave mail on server" mode
are as follows:
      Mark read : Y
      Show read : Y
      Show status : Y
      No delete : N
      Delete is final : <your preference>
Eudora has its own mechanisms (using the unix "status" header)
for determining whether mail should be downloaded or not, so
the normal mechanisms provided by MercuryP should be suppressed.
Mercury can expand distribution lists automatically, and includes
facilities for list moderation and automatic subscription.
1: Terms
List of lists
:  The master file describing all the lists
   managed by Mercury on this host. Specified in MERCURY.INI.
Public list
:  A public list is one to which anyone may
   subscribe by sending a
subscribe
 message to the maiser. If a
   list is not public, then only the list moderators may add to it by
   e-mail. A non-public list with no moderator can only be added to
   by manually editing the list file.
Moderator
:  The address of a person who has control over the list.
   If a list is "moderated" (see below) then mail can only be sent to
   the list by a moderator. If a list is "non-public" (see above),
   then only a list moderator may add subscribers to it. A list
   may have a practically unlimited number of moderators. A
   moderator need not be a subscriber to the list.
Restricted list
:  If a list is restricted, only its members and
   moderators may send mail to it.
Moderated list
:  A moderated list can only be posted to from
   addresses specified as moderators of the list. The intention is
   that mail is sent to a moderator who then decides whether it
   should be posted to the list. Moderated lists may or may not be
   public as well.
The "List of Lists" is pointed to by the "listfile" entry in
MERCURY.INI. It is a simple text file containing information about
the lists available on this host, and may be updated at any time.
List names start at the extreme left margin, and all subsequent lines
describing the list must be indented at least one space. Description
lines for a list are read until a blank line or another list name is
encountered. The name of a list may not have a domain attached -
lists can be reached on any domain served by the host.
Example:
test-l
   file:      sys:system/mercury/testl.lst
   title:     Test List
   welcome:   sys:system/mercury/testlw.txt
   moderator: [e-mail]
   moderator: [e-mail]
This entry defines a list called "test-l", with two moderators, a
title, and a greeting file for new subscribers. The following
qualifiers are supported by Mercury:
FILE:
       A required qualifier - the name of the file which
               actually contains the current membership of the list.
               The file need not exist before use - Mercury will
               create it automatically if necessary.
TITLE:
      Optional. Text added to the "to" field of messages sent
               out to list subscribers.
WELCOME:
    Optional. The name of a file to send to new subscribers
               to this list. The file is plain text, not a template
               file.
FAREWELL:
   Optional. The name of a file to send to subscribers
               when they are removed from this list. The file is plain
               text, not a template file.
MODERATOR:
  The minimal-form address of a list manager. List
               managers may add users to the list and may be the only
               people able to mail to the list. You may have as many
               MODERATOR entries as you wish, one address per entry.
               The FIRST moderator entry has special  significance -
               it is the "primary" moderator, the one to whom MAISER
               will refer users.

PUBLIC:
     Optional, Y or N (Default Y). Indicates whether the list
               is public or not. Non-public lists will not accept
               SUBSCRIBE requests.

RESTRICTED:
 Optional, Y or N (Default N). If 'Y', then only list
               members and moderators may send mail to the list.
MODERATED:
  Optional, Y or N (Default N). If 'Y', then only the list
               moderators may post to the list.

LIMIT:
      Optional, number (default 0). The maximum number of
               subscribers the list may have. If 0 (the default) then
               there is no limit.
ERRORS_TO:
  Optional, no default. Supplies an address to which
               errors generated by list mail should be sent. Note that
               this merely tells Mercury to generate an Errors-to:
               header in the message, which is quasi-standard. There
               is NO standard way of controlling or directing list
               errors, but this is as good as there is. Whether it
               has any effect depends on the receiving mailer.
REPLY_TO_LIST:
               Optional, Y or N (Default N). If 'Y', then Maiser will
               add a "Reply-to" field in messages to the list which
               will direct replies to the list rather than the sender.
ENUMERATE:
  Optional, Y or N (default N). If 'Y', then Maiser will
               accept ENUMERATE/REVIEW requests for the list.
FANOUT:
     Optional integer, default 1. Specifies the number of
               jobs Mercury should create when exploding this list.
               When a list is "fanned" (spread across multiple jobs)
               Mercury attempts to create the number of jobs you
               specify in this keyword and distribute the addresses
               evenly between them. This can result in faster
               distribution for large lists, especially if you load
               multiple copies of MERCURYC pointed at different smart
               mail hosts.
Users can subscribe to Public lists by sending a message to the
MAISER account on the server with the body set to SUBSCRIBE
<list-name>. Users can unsubscribe from a list using the command
UNSUBSCRIBE <list- name>. If a list is not public, then moderators
can add users to it by mailing to MAISER with the message body set to
ADD <list-name> <e-mail-address>, and may remove users by setting the
message body to REMOVE <list-name> <e-mail-address>. The command
ENUMERATE <list-name> will return the current list membership. If a
moderator has been specified for the list, then ENUMERATE will only
work for moderators, even if the list is not flagged as moderated.
Summary:
SUBSCRIBE <list-name>
         Add the sender's address to the list
  also
SUB <list-name>
UNSUBSCRIBE <list-name>
       Remove the sender from the list
  also
UNSUB <list-name>
  or
SIGNOFF <list-name>
ADD <list-name> <address>
     Add a user to a list (moderators only)
REMOVE <list-name> <address>
  Remove a user from a list (only list
                              moderators may use this command)
ENUMERATE <list-name>
         Return the list membership
  also
REVIEW <list-name>
                          Returns the lists available at this host
Mercury's mail server also recognizes the following commands:
               Returns the helpfile defined in the MAISER section
                   of MERCURY.INI to the sender.
BOUNCE
             Returns the message to the sender, headers intact.
LOOKUP <string>
    Searches the NetWare bindery for user names
                   matching <string>, which can contain '*' and '?'
                   wildcards. If you wish to disable lookup, make
                   sure that there is no LOOKUPFILE entry in the
                   MAISER section of your MERCURY.INI.
VERIFY <address>
   Returns a message indicating whether the address
                   specified is valid on the local host.

INDEX
              Sends the file INDEX.TXT from your "files to send"
                   directory (identical to the command SEND
                   INDEX.TXT).

SEND <filename>
    Sends the named text file from your "files to send"
                   directory. If you do NOT want this facility to be
                   available on your system, make sure that there is
                   no SEND_DIR entry in the MAISER section of
                   MERCURY.INI. The send command is VERY secure - you
                   cannot specify paths of any kind in <filename>,
                   and Mercury will ONLY look in the directory
                   specified in SEND_DIR.
FINGER <address>
   Returns information about the address supplied.
                   Also returns the contents of the file PROFILE if
                   it exists in the specified user's new mail
                   directory (useful for PGP keys and the like).
               Stop processing commands from the mail message.
Manuals for Mercury 1.13 are available immediately.
Mercury is free software, but to support its development, I make
manuals available for sale. Two types of manual are available -
single licenses, and licenses which allow you to make as many copies
as you wish for use at your site.
A single copy license gets you one copy of the Mercury Manual and the
most recent version of the program on disk. You may not make make
further copies of the manual. Single copy licenses cost US$150, which
includes courier delivery anywhere in the world.
Site licenses get you a single master copy of the Mercury manual and
a license which permits you to duplicate that master copy as many
times as you wish for use at your site. As with Pegasus Mail, a "site"
is considered to be the extent of your organization in one city. Site
licenses cost US$300, and again include both diskette and courier
delivery.
*** If you already hold a site license for any version of Pegasus
*** Mail, you may claim a US$75 deduction from the price of a Mercury
*** Site license. No deduction applies to a single-copy license.
Remember that manual purchases are optional - there is no obligation
for you to purchase manuals for Mercury, but if you do so, you are
making a positive contribution to its development and helping me to
support it.
To order a Mercury Manual, please print and fill out the order form
(see the menu for this - a copy of the order form is also supplied
in ASCII format as ORDER.FRM). Then send it with your cheque or
purchase order to:
        Pegasus Mail, c/- David Harris,
        P.O. Box 5451,
        Dunedin, New Zealand.
(or Fax [phone])
Purchase orders are accepted from any educational or charitable
institution or government department, and from companies with a paid
up capital in excess of $30,000.
Payment must be made in
US dollars, drawn on a US bank
. There is
usually a delay of at least 2 weeks before a manual can be sent out,
and I reserve the right to hold your order if a new release is
pending (so you can get the new release). Manuals are always sent
by Express Mail Service courier (2-4 day delivery anywhere in the
world), the fee for which is included in the purchase price.
All manual orders are shipped with a diskette containing the most
recent version of the program.
PLEASE, PLEASE!
 Remember to enclose the order form: I'm not psychic,
and I can't guess at delivery addresses from a cheque alone...
We can accept payment for Manual orders on any valid VISA or
Mastercard. If you wish to pay this way, please note your
card number, expiry date, and the name on the card on the
order form, and make sure you sign our order form.
Special Conditions:
*  Credit card payments attract a 2.5% surcharge which will
   be automatically added to the voucher.
*  The amount you are billed will probably not be exactly
   the amount on the order, because I have to submit the
   voucher to the VISA Centre converted to New Zealand
   dollars. I will use the USD conversion rate which
   applies on the day your order is processed.
I will accept payment by telegraphic transfer, but you
should be aware that there are some very particular
conditions you MUST meet for me to be able to do so.
Telegraphic Transfer Checklist:
------------------------------
  Your bank must not deduct any fees from the amount
   invoiced.
  Transfer to: The National Bank of New Zealand,
   Dunedin North Branch, account 060-909-0106632-13.
   The account name is "David Harris Pegasus Mail".
Your bank MUST ONLY TRANSFER TO MY BANK!!!
 If your
   bank transfers to me via any other bank in New
   Zealand, it will incur processing fees at this end
   which I will not accept.
If your bank cannot trans-
   fer directly to the National Bank of New Zealand,
   please pay by cheque. PLEASE ENSURE THAT YOUR BANK
   UNDERSTANDS THIS CONDITION!
 In particular, transfers
   via the Westpac Bank in New Zealand will be rejected
   outright.
  Please make sure that your bank states my invoice
   number in the transfer narration, so I can credit
   the remittance against your invoice.
A note to European users:  it appears to be common practice for
European Banks, particularly in Germany, to deduct fees from the
cheque they send. In some cases, these fees have been as high as
US$15.
Because of the costs of manual production, and the relatively small
amounts involved in the invoice,
DEDUCTIONS OF FEES FROM REMITTANCES
CANNOT BE ACCEPTED!!
  If your bank deducts fees from the remittance
you make, I will return the cheque unpresented for repayment. If
you prefer to make payments via direct credit to a bank account,
please contact me for details.
The following terms and conditions apply to all orders for Mercury
MTS manual sets. Submitting an order indicates acceptance of these
terms and conditions in their entirety, over and above any waivers,
disclaimers or conditions stated on the order itself.
-------------------- Terms and Conditions ------------------------
"Site license"
A site license for Mercury MTS manuals provides you with one master
copy of the manual and a license permitting you to make an unlimited
number of copies of that master for use at one site. A "site" is
defined as the extent of an organization in one metropolitan area, so
if you have four offices in one town, one site license will cover them
all. Only ONE organization may hold a site license - you may not
distribute copies of a site-licensed master outside your organization.
Note that State or National Governments and Local bodies do not
consitute organizations for the purposes of this definition. Site
licensed manuals include ASCII and RTF versions of the manual on
diskette.
"Single copy license"
You receive a single master copy of the manual, and a license
permitting you to make exactly one copy of that original for archival
purposes only.
"Media:"
All manual licenses include a diskette with the most recent version
of the Software.
Credit terms:
Our terms for payment on credit are STRICTLY net 30 days. No monthly
statement is issued - we require payment on invoice.
Shipment:
Shipment is by EMS (Express Mail Service). We cannot ship via UPS,
Federal Express, or any other courier company, and we cannot charge
freight to an account. We can ship by airmail on request - please
make sure the requirement is clearly stated on your order. Requests
for shipment by other means will result in delays, and may result
in your order not being processed.
Prepayment:
If you prepay your order, your payment will not be presented until
the day your manual is shipped. In general, we prefer that you do
not prepay orders - we would sooner receive a purchase order and
accept payment on invoice.
Pro-forma invoices, acknowledgments, quotations and bids:
Because of the sheer volume of paperwork we have to process, we
regret that we cannot supply pro-forma invoices, quotations or bids,
and cannot acknowledge receipt of orders other than via e-mail.
US IRS taxpayer requirements:
The vendor is not an American citizen and is not resident in the
United States for tax purposes: consequently, requests for FEINs,
social security numbers or other US Taxation requirements cannot
be complied with and will receive no reply.
Withholding taxes on payments:
We will not accept payments from which withholding tax deductions
have been made unless those deductions have been made in compliance
with the laws of New Zealand. If you deduct withholding tax from
your remittance, your payment will be rejected even if you do so in
compliance with the laws of your own country. Such deductions are a
matter between you and your own government.
Credit card payments:
* A 2.5% surcharge applies to credit card payments
* Credit card payments will be converted to New Zealand dollars
  using the prevailing exchange rate on the date your manual is
  shipped to you. The amount you see on your credit card statement
  will probably not be exactly the amount shown on the order form
  above.
       Press <F10> and choose "Edit" to fill in this order form
 Please read "Terms and Conditions" at the end of this form carefully.
         +--------------------------------------------------+
         |         O R D E R   F O R M,   v 1 . 1 3         |
         |                for Mercury Manuals               |
         +--------------------------------------------------+
 Ship to:                            Bill to:
[                            ]      [                               ]
[                            ]      [                               ]
[                            ]      [                               ]
[                            ]      [                               ]
[                            ]      [                               ]
Date this order was mailed          [   ] Day  [   ] Mon  [   ] Year
What is your purchase order number  [                               ]
 or: Credit card type (tick one)    [   ] Visa [   ] Mastercard
     Card number (print carefully)  [                    ] exp: [   ]
     Name shown on card             [                               ]
Number of invoice copies required   [   ]
Internet e-mail address of contact  [                               ]
Fax number of contact               [                               ]
Order status and update information cannot be sent if you do not
provide either a contact e-mail address (preferred) or a fax number.
If paying by credit card, you must sign the copy of this order form
you send to us.
Please supply the following items:
----------------------------------------------------------------------
[  ] Single manual license for Mercury @ US$150 . . . .  US$ [       ]
[  ] Site-licensed manual for Mercury @ US$300  . . . .  US$ [       ]
[  ] We already hold a Pegasus Mail SITE license - please give
     us a US$75 deduction from a Mercury ->SITE<- license purchase!
----------------------------------------------------------------------
Ordering instructions:  Please complete this form, and send it via
airmail with your cheque or purchase order to:
    Pegasus Mail, c/- David Harris,
    P.O. Box 5451, Dunedin,
    New Zealand.
or fax it and your purchase order number to: ([phone].
Shipping via EMS courier is included in the price of any option.
Please allow 2-3 weeks for your order to be processed.
------------- Definitions, Terms and Conditions ------------------
Pricing:
All prices are shown in US dollars and payment must be made in USD
drawn on a US Bank. If you would prefer to pay the equivalent amount
in another currency or by other means, please contact us for information.
New Zealand customers may pay in New Zealand dollars - please contact
us for a current conversion rate.
"Site license"
A site license for Mercury MTS manuals provides you with one master
copy of the manual and a license permitting you to make an unlimited
number of copies of that master for use at one site. A "site" is
defined as the extent of an organization in one metropolitan area, so
if you have four offices in one town, one site license will cover them
all. Only ONE organization may hold a site license - you may not
distribute copies of a site-licensed master outside your organization.
Note that State or National Governments and Local bodies do not
consitute organizations for the purposes of this definition. Site
licensed manuals include ASCII and RTF versions of the manual on
diskette.
"Single copy license"
You receive a single master copy of the manual, and a license
permitting you to make exactly one copy of that original for archival
purposes only.
"Media:"
All manual licenses include a diskette with the most recent version
of the Software.
Credit terms:
Our terms for payment on credit are STRICTLY net 30 days. No monthly
statement is issued - we require payment on invoice.
Shipment:
Shipment is by EMS (Express Mail Service). We cannot ship via UPS,
Federal Express, or any other courier company, and we cannot charge
freight to an account. We can ship by airmail on request - please
make sure the requirement is clearly stated on your order. Requests
for shipment by other means will result in delays, and may result
in your order not being processed.
Prepayment:
If you prepay your order, your payment will not be presented until
the day your manual is shipped. In general, we prefer that you do
not prepay orders - we would sooner receive a purchase order and
accept payment on invoice.
Pro-forma invoices, acknowledgments, quotations and bids:
Because of the sheer volume of paperwork we have to process, we
regret that we cannot supply pro-forma invoices, quotations or bids,
and cannot acknowledge receipt of orders other than via e-mail.
US IRS taxpayer requirements:
The vendor is not an American citizen and is not resident in the
United States for tax purposes: consequently, requests for FEINs,
social security numbers or other US Taxation requirements cannot
be complied with and will receive no reply.
Withholding taxes on payments:
We will not accept payments from which withholding tax deductions
have been made unless those deductions have been made in compliance
with the laws of New Zealand. If you deduct withholding tax from
your remittance, your payment will be rejected even if you do so in
compliance with the laws of your own country. Such deductions are a
matter between you and your own government.
Credit card payments:
* A 2.5% surcharge applies to credit card payments
* Credit card payments will be converted to New Zealand dollars
  using the prevailing exchange rate on the date your manual is
  shipped to you. The amount you see on your credit card statement
  will probably not be exactly the amount shown on the order form
  above.